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COMHMENtS AGAINST ROUTING M-E ERS. 



following are my comments against routing ME ERS. 
MT^t of these comments are editorial which i think will 
help in improving the readability of the document. The 
document in general looks good. 



Page 1-2 Section 1.1 

•Routing MEs receive RIOUs from other mufti-homed systems 
rather than networks. 

Page 2-1 Section 2.1.1 

•Restate the sentence 'At a high level* the routing HE may 

be seen as •as 'At a high level* the routing ME may 

be seen as being responsible for computing the best paths 
to all networks in the catenet from the local system. These 
paths are recomputed whenever a network in the catenet becomes 
active or Inactive or becomes congested or uncongested*. 

Page 2-2 Section 2.1.1 

•Change 'maximum number paths' to 'maximum number of paths 1 . 
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Page 2-2 Section 2.1.2 . 

.State that the network cost is divided by 4 when the network 
congestion status changes from congested to uncongested. 

Page 2-2 Section 2.1.3 

•Restate ''routing around downed networks' as 'routing around 

inactive networks'. 

>. Page 2-6 Section 2.1.5 

•Restate 'In addition* each row has a flag in it ' as 

'In addition* each row has a flag in it* which is true If the 

network is directly connected to the system'. 

r. Page 2-7 Section 2.1.5 

•Routing ME would have to do a transformation from CONAs XEROX 
RIOUs rather than CONAs XEROX routing tables, 

3. Page 2-8 Section 2,1.6 

•Restate 'Therefore* it Is Important to Include the 3A commands' 
as 'Therefore* It Is important to send the 3A commands'. 

3. page 2-9 Section 2.1.7 

•Since Rl does not support true xerox networks* the concept of 
routing info networks should be deleted. 

•The frequency of RIOU generation is determined by changes In the 
local network titles/address data store in addition to the other 
two factors mentioned in the 2nd para. 

Page 2-11 Section 2.2 '..... 

.In the description for »R'» mention that routing ME sends and 
receives RIOUs to/from other systems via generic 3A. 
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1. Page 2-12 Section 2#3 

•Change 'buffer management timer' to 'buffer management* timer*. 

2. Page 2-12 Section 2.3.1 

.Need to specify that when the changes in the local DCNs are 

C>, communicated to routing me> it recomputes the routing tables 
^ in addition to generating RIDU If multihomed. 

3. Page 3-1 Section 3.1.1 

•Restate the last para In this section as 'When routing HE is 
going down, it notifies the internet entity. This is covered 
in section 10.0 under aborts and recovery'. 

A. Page 3-5 Section 3.2.1 

•Delete reserved sap id for routing ME as It uses the services 

of 3A. 

5. Page 3-6 Section 3-2.2 

•Describe mi smatch_user_id as 'The input user.id does not match 
the user.ld in the entry for the input sap.ld'. 

•The description for sap. air eady_closed should say 'attempting 
to close an already closed sap'. 

.6. Page 3-7 Section 3.3 

•Only the broadcast titles are calculated. The broadcast address 
for remote networks Is communicated via RIDUs. 
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•In the last para* mention that as part of RIDUs* multi-homed 
systems send community title/address pairs and broadcast address 
(i.e If the network is a broadcast network). 



.7. Page 3-7 Section 3.4 

•Delete references to routing info network. 

•Restate 'when some attribute changes' as 'when some attribute of 
the local directly connected network changes', 

L8. Page 7-2 Section 7.0 _,_ 

•Criteria for rebuilding ICR-DS needs to be clarified. The following 
points should be highlighted: 
.Criteria for rebuilding LCR-DS Is 

•Any change in the local den attributes, 

•Any change In remote den status. 

•Any change in remote den's relay allowed attribute. 

L9, Page 8-1 Section 8,1 ....,..* 

•There should be another flag In the least.cost.routlng.ds.entry 

to reflect the entry status. 

20. Page 8-5 Section 8.4 

.The 'kind' field In nw.ti tle_addr„ds_entry has a value 'xerox' 

which is not needed. 
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.The title.length should be 1..32 instead of 0..41 as the 'kind* 



field specifies the type of title. 
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ROUTING H-E ERS 
l.C INTRODUCTION 




l.C INI£CJJU£II£Ii 



In the OSI env i r onment* the ISO standards define two kinds of 
management* namely management of the network and management of 
each layer. The layer management functions in the Internet 
(3E) layer are grouped together under the name of Routing 
Management Entity. As such* it has a direct interface with 
M 3A" entities below* specifically* the Generic 3A. 

Pouting Management is one of the most important of all 
management functions in the catenet. The stability and 
robustness of the catenet depends on the accuracy of the 
routing tables and the speed with which the Routing M-E reacts 
to failures and congestions in the catenet. 

In Release 1* the Routing M-E will support only the Xerox 

, Internet. In subsequent releases* it is expected to manage 

|> multiple Internet entities. It is not expected that every 

^•-^ system will have more than one Internet* rather that only some 

systems which interface to different networks such as NI»s» 

will support this feature. This document addresses the one 

internet catenet and lays the groundwork for multiple 

internets. 



1.1 £UE£ILS£ 



The purpose of the Routing M-E is twofold. The first is to 
build and maintain the data stores shown below: 

Least Cost Routing Data Store (LCR-DS) 

Alias List 

Local Directly Connected Network Data Store (LDCN-DS) 

Received DCN Data Store (RCCN-DS) 

Network Titles/Addresses Data Store (dedicated and remote) 

3B SAP (Service Access Point) Data Store 

The second purpose is to generate and broadcast Routing 
Information Data Units (RIDUs) to other Routing M-Es in the 
catenet. This is true only of systems located on more than 
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one network* which are called multi-homed systems. However* 
Pouting F-Es in ail systems receive RIDUs from multi-hoired 
systems. 

In general* the purpose of the Routing M-E is to perform all 
layer management functions for the Internet layer* so that the 
Internet layer itself can do fast routing without the burden 
of an y overhead. 



1.2 R£E£EE£!C.ES 



^uuJr 



1. CDNA CDS by J H Hart ( ARH4243) 

2. CDNA Routing M-E Protocol Specification by P R Sekhon 

3. Xerox Internet Transport Protocols XSIS 028112 

4. Xerox Internet EPS by P Woodruff {ARH6221) 

5. Directory M-E ERS by H G Coverston (ARH6384) 

6. intranet 3A ESS by K D Lamar 
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The services offered by the Pouting H-E are: 

Maintaining the Least Cost Pouting Data Stores (LCR-CS) 
and Alias List and the Local and Received DCN Data Stores 
which are used to build them. 

. Generating and broadcasting Pouting Information Data Units 
(PIDU) about local Mrectly Connected Networks and 
Community Titles *ith their associated multicast addresses 
by Routing f*-Es in multi-homed systems. This information 
is learned from the Generic 3A status interface. 

• Receiving* processing and rebroadcasti ng the above 

mentioned RIDUs. 

Registering of Network T I t I es/ Addresses with the Directory 
V-E for use by software modules in the DI; these 
Titles/Addresses are learned from Generic 3A and RIDUs. 
. Opening and closing of 35 SAP's and related maintenance of 
the Internet SAP Table. 



2.1 E£AIUP.£SIS££JiKES 
2.1.1 OVERVIEW 



This section explains how the functions of the Routing M-E are 
perceived by external processes including users. At a high 
level* the Routing P-E may be seen as responsible for 
computing the "best" paths to all networks in the catenet from 
the local system. These pathes are recomputed whenever a 
network in the catenet becomes active or inactive* or becomes 
congested or uncongested. Thus* without any human 
intervention* the catenet reacts auickly to changes in the 
attributes of the networks or the topology of the catenet. 

A "path" from one system or network to another network is 
defined to be a sequence of links (networks) which are 
characterized by: 

The first link in the seouence connects to the source 
and the last link connects to the destination. 
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There are no duplicates 
The maximum number of 
connected networks at 
dest i nation. 



in the sequence 

paths is number of directly 
the source which lead toward the 



2.1.2 COST OF PATHS 



c 



For Release 1.0* the 'bast' path is defined as the one that 
has the lowest cost. The cost of a path is the sum of the 
costs of the links. The ccst of each link is supplied by 
Gereric 3A to its Routine tf-E . The algorithm for cost 
definition (based on line speed) is given in section 7.1.2.1 
of the 60S. 

Another factor which influences cost is congestion. The GDS 
lists two thresholds of congestion but does not define them. 
To keep it simple for Release l.C, the network is assumed to 
be either congested or unccngested. If a network changes to 
congested, the Routing tf-E multiplies the cost by A. 
Conversely, the network cost is divided by A if the congestion 
state changes back to uncongested. 



2.1.3 RESPONSE TO FAILURES 
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Another major function of Routing M-E 
application resides in a system which 
multiple networks, then it really has 
per network. However, it chooses on 
register with its title. Pouting 
network address which all application 
problem arises if the primary netwo 
can still be reached by means of the r 
Routing M-E is responsible for th 
messages along the active networks eve 
still being addressed to the system vl 



is the fo I lowing: If an 
is directly connected to 

multiple addresses, one 
ly one among them to 
M-E provides the primary 
s use. A non-tr i v i al 
rk fails, and the system 
emaining networks. The 
e smooth re-routing of 
n when the messages are 
a the broken network. 



Before addressing broken networks in the destination systems, 
routing around inactive networks between the source and 
destination will be exairined. The first examp I e, pi ctur ed 
below, shows a trivial case where a network cne hop away 
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breaks down: 



!HCST ! 
+ — +--+ 



■ 
+ — + — + 



+ — + — + 

« 
i 

PDN 



♦ — + — + 
JNDI3 \ 
♦ — ♦ — + 



NID«1 



+— + — + 
JNDI1 S 



Nir>*2 



+ + 4 

!NDI2 ! 
+ — + — + 



b 
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i 

+ — + — + 

i tdi : 
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It is assumed that the best path from the TDI to the host is 
via NJD»2. If NID*2 breaks down* NDI2 would receive the 
message from the TDI destined. for the host and then re-route 
it via NID*3 through NCT3. A different situation occurs if 
the link between NDI1 ana the network with NID*1 breaks. NDI1 
would re-route the message back to NDI2 and it might oscillate 
tack and forth between NDIi and N0I2. Put these are all 
transient conditions and would go away as soon as NDI1 sends a 
new RIDU informing the catenet of the failure of its 
connection to NIDI. 

The next example is shown in the following diagram: 
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NID6 
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NIC 7 
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J TDI J 



Assuming that NID2 is the primary network for the HOST/MFI, 
all applications in that system register their titles using 
the NID2 and the system ID on that network as part of their 
address. Assuming that the best path from the TI to the 
HDST/MFI is via NID6» NID4t and NID2> there are two problems 
whose solutions are discussed below. 

1 - If the best path gets congested* how does the TI use the 

alternate route NI05* NIC3» NIDI? 

2 - What happens if the NID2 goes down and becomes inactive? 



o 



CONTROL DATA PRIVATE 



POUTING M-E ERS 



2-5 
07/25/84 



2.0 FEATURE/SERVICE OVERVIEWS 
2.1.3 RESPONSE TO FAILURES 



1 - A I terna te routes 



b 



host is multi-homed* it would send RIDUs between 
NID2. As the path to the host via NID2 becomes 
the TI would send the messages via NIDI assuming 
would be relayed to NID2 unaware that the messages 
destined for the HOST/MFI. Vhen the messages get 
HOST/MFI via NIDI* they are delivered to the 
applications instead of being relayed. This poses 
problem: systems in the catenet may use the host as 
which is a waste of the precious resources of the 
is addressed later on. 



Si nee the 
NIDI- and 
congested* 
that they 
are really 
to the 



another 
a re I ay* 
host. This 



2 - A I ias Li st 



Us in 
addr 
pr im 
i n c 
When 
NIC2 
alia 
NIDI 
cann 
al ia 
NIS2 
addr 
go t 



g 

esse 

ary 

aten 
NID 
/SID 
s.l » 
/SID 
ot 

s.ti 

/SID 
es-s 

hr ou 



this 
s: N 
addr 
et r 
2 go 
2 is 
st 

1 is 
find 
st. 

2 i 
NIDI 
gh t 



e 

ID2/ 

ess. 

eal i 

es d 

ina 

entr 

equ 

an 

Si 

s f 

/SID 

he s 



xamp 
SID2 
If 
ze t 
own* 
cti v 

y < 
i va I 

en 
nee 
ound 

1. 

ame 



I e> a 

and N 

NID2 

hat th 

the P 

e. S 

descr i 

ent t 

try f 

an e 

, the 

Each s 

oroces 



ssurr 
ID1/ 
beco 
e ho 
IDUs 
ys te 
bed 
c N 
or N 
ntr- 
3B-t 
yst> 
s . 



e tha 
SID1 o 
mes in 
st can 

from 
ms in 

i n se 
ID2/SI 
ID2 in 
for 

ru is 

ir wh ic 



t the 
f whic 
active 
sti I I 
the HO 

the 
ct ion 



D2J t 

the L 

the 

sent t 

h rel a 



HOST/* 
h NID2/S 
» how do 

be reac 
ST/MFI i 

catenet 
8.2) ind 
hus» wh 
CR-DS* i 
destinat 
oward th 
ys this 



FI 
ID2 

the 
bed 
nd i c 
cr 
i cat 
en 

t ch 
i on 
e ea 
3B-P 



has 

is 

sys 

by N 
ate 
ea te 
ing 
Inte 
ecks 
add 
ui va 
DU 



two 

the 

terns 

ID1? 

that 

an 

that 

rnet 

the 

ress 

lent 

must 



In this exampl e» i f the 
NID2 remains up for NDI1* 
NID2. Therefore* the 
al i as.exi sts* to indicate 
this network. If this 
checked to see if an 
network/system ID. In 
destination NID2/SI02 is 



HOST/MFI access NID2 goes down 



but 

an LCP-DS entry will still exist for 

LCR-DS contains a boolean field* 

that an alias_list entry exist for 

field is TRUE* the alias.list is 

entry exists for the destination 

this example* an entry for the 

found, and the 3B-PDU is sent toward 



NID1/SID1. 
tc the final 



As above* this 
dest i na t i on . 



process is repeated for all relays 



2.1.* MULTIHOMED HOSTS 
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The problem of how i 
systems from using 



multi-homed system may prevent other 
it as a relay is addressed here. The RIDU 
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(described in section 8.3) includes a boolean field called 
"relay^restr icted" for each "dcn_def i n i t ion.entry" which is 
used in the following way: The combination of two particular 
networks in a system cannot be used for relays if k&Lh have 
the "rel ay.restri cted" field set TRUE. When the LCR-DS is 
generated for a given system* the "r e I ay_restr i cted" fields of 
RIDUs are consulted and routes constructed such that no 
unallowed relays occur unless no other path to a destination 
exists. If there are* for example* two Ethernets and an LCN 
connected to this host* the " re I ay_re st r i cted" fields are set 
i n the f ol lowing way: 



Ethernet 1 
Ethernet Z 
LCN 



- relay.restr icted - TRUE 

- re I sy_r estr i cted * T&UE 
re I av.restr i cted = FALSE 



To find out if relay between Ethernet 1 and Ethernet 2 is 
legal, take the logical "AND" of the two. The result in this 
case is TRUE which means that the relay is not legal (unless 
only path to destination). It may be seen further that relays 
between the LCN and either of the Ethernets are legal. It is 
to be noted here that the multi-homed system itself* which set 
the flags in its RIDU* doss not enforce It. It leaves it to 
the Pouting M-Es in other systems in the catenet to honor this 
flagi-n computing the LCP-DS's. 



2.1.5 USE OF LEAST COST ROUTING DATA STORE (LCR-DS) 



In CDNA systems* the Least Cost Pouting Data Store (LCR-DS* 
described in section 8.1) contains one row for each network ID 
in the Catenet that can be reached from the local system. In 
addition, each row contains a boolean field* 
"directty.connected", which is set TRUE if the network is 
directly connected to this system. 

The Internet Layer is the main user of the LCR-DS. Its use is 
described in the Xerox Internet ERS. In general, Internet 
uses the LCR-DS to find if this system Is the final 
destination or the next hop for a 3B-PDU on its way to the 
final destination. If it is determined that 3B-PDU is bound 
for this system, the 3B SAP table (described in section 8.6) 
is used to locate the Internet user. 
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After the Routing M-E has calculated a new LCR-DS* a pointer 
to the current LCR-DS is changed to the new one. Then the old 
LCP-CS buffer space is released. Because Internet is 
non-preemptab I e» tasks using Internet complete their use of 
the LCR-DS in one time slice. Thus* Internet is unaffected by 
the change of the LCR-DS. 
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2.1.6 DIRECTORY M-E REGISTSATICN OF TITLES/ADDRESSES 



Community titles and corresponding multicast addresses and 
broadcast titles and addresses for broadcast networks are 
registered with the Directory M-E by Pouting M-E. The 
community titles/addresses are learned from Generic 3A for 
directly connected networks and received RIDUs for remote 
networks. The broadcast title/addresses are calculated from 
known local and accessible remote networks contained In the 
RIDUs (as described in section 3.3). The title address 
information is available to software module in the DI which 
need a translation of Network Titles. 

For example* C170 systems SI and Sll are located on Network Nl 
and systems S2 and S21 on Network N?; their multicast address 
Is '123'. A set of configuration commands processed by 
Generic 3A describe community title/addresses as shown below? 



o 
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Nl 



;si j 
+— + 



:ti s 
+- — + 



JS11J 
+ + 






N2 



i 



+ + 



♦ ■ 



NI 



- + 



♦ -+- + 

:ti j 

♦— + 



!S2 : 

+— -+ 



+-♦-♦ 

5S21! 
+— - + 



sti : 
+ — + 



♦-+-♦ 

STI ! 
♦— — + 



o 



c 



Systems SI and Sll are told that they belong to a community 

whose title is "commun i t y_C 170 Host"* and their multicast 
address is "123". 

Systems S2 and S21 are told that they belong to a community 

whose title is "commun i ty_C17C Host"* and their multicast 
address is "123". (Note: the two multicast addresses need 
not be the same) • 



- The NI is told that the OCN 
called "communi ty..Cl70 Host" with 
"123" and that th NI itself is not 



"Nl" supports 
a mu 1 1 i cast 



a community 
address of 



part of It. 



- The NI Is told that the DCN "N2" supports a community 
called "ccmmuni ty_C170 Host" with a multicast address of 
"123" and that the NI itself is not part of the community. 




When a remote network called "N<?" gets the RIDU from this NI* 
the Routing M-Es in all the systems on N<? register the title 
"communi ty_C170 Host" and the address »123« with their local 
Directory M-Es. In this way* any application In the remote 
system desiring to communicate with all C17C hosts* would 
obtain the translation (2 entries in the translation, one with 
address NID*1»SID=123 and the other with NID=2»SI0«123 J from 
its local Directory M-E and establish communication. The TI's 
on Nl and N2 would also learn of the title/addresses in the 
same way. 
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Q 



o 



If the catenet consists of one network* i.e.: one Ethernet 
with a few TI's and one or more hosts* RIDUs are not 
automatically generated by any of the systems. Therefore* an 
Intranet configuration command is provided to force 
single-homed systems to generate RIDUs. This is the only way 
for community title information to be broadcast in a single 
network catenet. 

To sum up» the 3A configuration commands to define communities 
would be sent to: 

All single-homed systems which are part of the 

community. 

- All multi-homed systems in the networks where the 
c on mun i t i es exist. 

The command would have the following information: 

- Community name 

- Multicast address (NIC ♦ SID) 

- Whether this system is part of the community 

The community name and the multicast address would be saved in 
a data store and if not previously registered* would be 
registered with the Directory M-E. 



2.1.7 BROADCAST/RE-BPOADCAST OF RIDUS 



If the Local DCN Data Store contains two or more entries* the 
Routing M-E on this system generates RIDUs and broadcast them 
on al I acti ve DCN's. 

The frequency is determined by: 
- once every 30 seconds 

whenever the local DCN Data Store changes (network or 
community)? the timer is reset to zero 

The RIDU is generated from information in the Local DCN Data 
Store and the Network Titles/Addresses Data Store in the 
manner described in section 7. 1.3. A of GDS. 

If the number of defined DCN entries referred to earlier is 
reduced to one* the generated FICUs are still broadcast on the 
remaining DCN for 9C more seconds at the specified interval. 
Since the "out of date" timer has a value cf 90 seconds* it 
takes that long in the worst case for all remote networks to 
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RIDUS 



real ize the 
be directed 



loss of the DCN. During that time* 
at this system via the lost DCN. 



messages could 



If a- local network access goes down* the RIDU still contains a 
DCN entry set to "inactive". Receiving systems create 
alias. list entries as explained in section 2.1.3 in order that 
38-PDUs can still be delivered. 

Every received RIDU whose sequence nuirber is greater than 
previous ones generated by a particular system is re-broadcast 
on all DCN's in the Local DCN Data Store marked as "CCNA 
Routing Information Network" and active except the one DCN 
from which the RIDU was received. Therefore* s i no le-hcired 
systems do not re-broadcast. 

Release 1.0 of Routing M-E does not deal with processing 
requests from and issuing replys for "true" Xerox system. 






2.1.P OPENING/CLOSING OF SAP'S 



As the, management entity for the Internet Layer* the Routing 
f-E is responsible for opening and closing Internet SAPs upon 
recuest from Internet users. The interface between the 
Internet user and Routing **-E is by direct call. The 
Interface specifications* concepts and functionality are 
described in section 3.2. 



0- 
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2 . 2 £U!imi:til!-££LAII££i£tiIES 






+ + 



Directory — T-> 

M-E + 



Internet Users 



+ + p +-. +-+ s ♦-+ — + + P +— -+ 

? V ! Al ias List ! V 

♦ + • 

Pouting M-E — M-> LCP-DS — U-> Xerox 

+ + Internet 

!3F SAP Table ! 

V V V 

Generic 3A and Intranet Entities 



+ __—.—— _ — - — — .— — — 



— .«. _+ 



o 



o 



SSR's 



Fi gure 1 

Interfaces in Figure l: 

D - Pouting M-E registers title/addresses 

T - Internet users request title/address translations 

S - Routing M-E ooens 3E S#Ps for Internet users 

P - Xerox Internet sends data to/from Internet users and 3A 

M - Routing M-E maintains routing tables 

U - Xerox Internet uses routing tables 

3 - Routing M-E opens a 3A SAP and receives network status 

R - Routing M-E exchanges RIDUs with other systems via 3A 

Figure 1 above shows how Routing M-E relates to Xerox 
Internet* its users* Generic 3A» Directory M-E and routing 
tables. Routing M-Es main function is to build the LCR-DS 
which Xerox Internet uses to determine the route for 38-PDUs. 
The Alias list maintains information about inactive network 
interfaces. Routing M-E uses a direct interface to Generic 3A 
to open a 3A SAP and receive information about directly 
connected networks. Also* RIDUs are sent to and received from 
other systems via 3A. Pouting M-E opens and closes 3B SAPs. 
Community titles learned from Generic 3A and RIDUs and 
calculated broadcast titles are registered with the Oirectory 
M-E. 
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2 . 3 y.IILIZ££_E ilEE 3. AL-IM IE ££ *£££ 



AM the interfaces to Exec and Common 
buffer management* timer* etc. are not 



Subroutines such 
included here. 



as 



2.3.1 GENERIC 3A 



o 



Routing M-E uses the services cf Generic 3A to open a 3A SAP 
and to get the status cf underlying networks. Community 
titles/addresses are included with the 3A network information. 
The interface to Generic 2* and the format of the Network 
Information Block which describes local networks and community 
titles is described In the Intranet 3A ERS . Based on status 
changes* the local DCN data base is updated and the LCR-DS 
recomputed; and if necessary* new RIDUs are broadcast to the 
entire catenet. Generic 3A status indications are 
unsol ic i ted. 

The Pouting M-E also uses 3A to exchange Routing Information 
Data Units (PIDUs) with Pouting M-Es in other systems. 



2.3.2 DIRECTTRY M-E 



Pouting M-E registers all community titles/addresses of both 
directly connected and remote networks *ith the Directory M-E. 
This enables any entity In the network to find out* for 
instance, the addresses of all C170 hosts (if C170 hosts is a 
community). In general* community titles are learned from 
Generic 3A and RIDUs. Interface to the Directory M-E is 
described in the Directory M-E EPS. 
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3.0 ££ATU££_£££££I£IIC!i£ 



D 



The features of the Pouting M-E are described in this section. 
Each subsection discusses a particular interface across which 
services are offered. 



3.1 £E£\£I££-ICI£iIE££EI 
3.1.1 FUNCTIONAL CONCEPTS 



There is no formal interface between Pouting M-E and Internet. 
In general* it is the Routing M-Es responsibility to manage 
all the tables and data structures used by the Internet 
entity? so that the Internet entity can perform its services 
speedily. When the system is loaded? the Internet is rot 
completely operational until the Routing M-E has gone through 
the initialization process described in section 7.0. When the 
process is complete? an Internet user can open a SAP? and a 
sufficient LCP-OS is present in order for Internet PDUs to 
reach their destination. 

When Routine M-E is going down* it notifys the Internet 
entity. This Is covered in section ICO under Aborts and 
Recovery. 



3.1.2 GENERATION OF LCR-DS 



The most notable process accomplished by the Pouting M-E on 
behalf of Internet is the generation of the Least Cost Routing 
Oata Store (LCR-DS). In general? the LCR-DS (described in 
Section 8.1) specifies which system on which directly 
connected network to send an Internet Protocol Data Unit 
(3e-PDU) on its way to the final destination. The use of the 
LCR-DS by Internet is described in the Xerox Internet EPS. 
The process used to generate the LCR-DS is described in the 
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CDNA GDS and The Routing M-E IDS. A pointer to the current 
LCR-DS is kept in the following variable: 



-VAR 



current_LCRDS_ptr s [XREF1 *r oute.tab I e.row J 



o 



I 
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(^ 3.2 INTERFACES TJ 

3.2 LtLIEEEAr.ES.,IILBEEMZClBS.E.JE-.SAEIS 



b 



© 



On behalf of the Internet entities* the Routing H-E opens and 
closes 3B SAP's. 



3.2.1 OPEN INTERNET SAP 



When an Internet user wants to open an Internet SAP* he Issues 
a call to the open_i nter ret_sap procedure. A dedicated 
well-known or ephemeral (dynamically assigned) SAP can be 
opened. In general* the user describes the SAP he wants to 
open and supplies procedure interfaces. The open SAP ID is 
returned along with the procedure address for Internet. Below 
is shown the procedure interface to open an Internet SAP and 
the associated CYBIL parameter records. 

PROCEDURE CXPEF1 open_i nternet.s ap < t 

input. param: *open_sap_input_par ameter s; i INPUT 
,output_param: "open.s ap_outPUt_par aireters 5 C INPUT 
VAR return~code: open_inter ne t_sap_s tatus ) ; { OUTPUT 



C 

•C INPUT parameter record for open INTERNET (38) SAP 

C 
TYPE 

record ■ open_sap.lnput_parameters 

sap. id: sap_id_typej I If <> 0: Requested Dedicated SAP ID 
user_id: "cell! { user identifier 

destination: des ti nat i on_3b_sap_if ; C Proc for 3B ind 
force_close: f or ce_c I ose_i f ; < Procedure to close 3B SAP 
recend; 



{ User procedure interface to receive Internet Indications 

TYPE 

destination_3b.sap_.if « *procedure ( C 

ind_params: *internet_i nd_i f )» C INPUT 

~* € - 3B data ind params 
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internet_ind_i f = record i 3B Data Indication parameters 
multicast: boolean* { TRUE»mul ti cast* FALSE* datagram 
checksum: boolean* { TRUE if message Has checksummed 
-source_address : internet_adtiress» 
destlnation_address: internet_address* 
control: contro l.bytes* i hop_cour>t and packet.type 
user.id: "cell* { user.ID for this SAP entry 
data: buf_ptr» -C message buffer descriptor address 

recend; 



User procedure interface 

for Pouting H-E to close an INTERNET (3E) SAP 



TYPE 

f orce.c I ose_i f « ^procedure ( { 

sap_id: sap.id.type; C INPUT - SAP ID of SAP 
user.id: A cell); { INPUT - user identifier 



to cl ose 



C 

f OUTPUT parameter record for open INTERNET I3B) SAP 

C 

TYPE 

record » open_sap„output_p8r ameter s ! 

local_i nternet_address: internet_address ; C assigned SAP ID S 
I. n f ternet_request : internet _request_aariress> 

max i mum_request_ length : 1 •• max_d ata_ I ength ; { 

recend; 

C 

C Return codes from open_ i n ternet_s ap 

I 

TYPE 

open_internet_sap_status » ( { 

open_sap_success f u I * { SAP was opened successfully 
internet. down) ; { INTERNET not available 
i I legaf.dedi cated.sap* -C This dedicated SAP ID too high 
sap_al r eady_opened* {This dedicated SAP is already open 
no_sap_entr i es_avai I ab I e* { All SAP table space in use 
internet. down) ; { INTERNET not available 



V > 



O 



The Routing !*-E has a list of well-known SAP's that can be 
opened. As mentioned above* the user can explicitly open one 
of these by specifying the SAP value in the epen_internet„S8p 
procedure call. The dedicatee* Irternet SAP values are as 
f o I I ows : 
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o 



o 



CONST 

C Interface via Internet (3B) Layer 

Rout i ng_me_sapi d * 1(10)* i Reserved for future use 

Echo_me_sapi d = 2(10)* 

Error_me_sap id « 3(10)* 

Di rectory_me_sapi d « 20(10)* 

F i le„.Access_me..sap id = 21(10)* 

Coromand^me.sapi d * 22(10)* 

Log_me_sap id * 23(10)* 



i Interface via Transport (A) Layer 

Di rector y_me_xp_sapi d * 102C{10)» 

F i I e_Access_me_xp_sap i d ■ 1021(10)* 

Command_me_xp_sao i ti - 1022(10)* 

Log_me_xp. sapid = 1023(10)* 

■C Ephemeral Internet SAPs 

request_ephemer al _s ap * 0(10)* 

f i rst_ephemer a l_sap = 3001(10? 



The range of SAP's 1 thru 3000(10) are for dedicated SAP's 
which is in conformity with Xerox's definition for XNS 
networks. AH others are ephemeral* i.e.: they are 
dynamically assigned and reused. Ephemeral SAP's are assigned 
on the following basis. A variable in.- b.aitfiX^rb>acJl£d— S.AH 
holding the next available ephemeral SAP is initialized to 
3001(10). Every time a new ephemeral SAP number is needed* 
the following steps are performed: 

Step 1 - A check is made to see if the number in the 
variable Is already assigned and active. If so* 
the variable is incremented by 1. If less than 
65536* repeat Step l; otherwise* set variable to 
3001 and repeat Step 1. 

Step 2 - Assign this number and update tables. 

Step 3 - Increment variable by 1. If less than 65536* 
quit. Otherwise set variable to 3001. 

This method makes sure that de-assigned SAP's remain unused 
for a long period of time for analysis and debugging purposes. 
It also prevents an application from being assigned a newly 
released SAP and receiving a message meant for the previous 
application which released that SAP. The variable's location 
in battery-backed PAM assures that this method will not be 
disrupted by either system re-loads or power failures. 
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When an Internet user wants to close an Internet SAP* be 
issues a call to the c I ose_internet_sap procedure. In 
general* the user specifies the SAP he wants to close. Below 
is shown the procedure interface to close an Internet SAP and 
the associated parameters: 



PROCEDURE [XPEF3 c I ose.i nter net.sap ( { 

sap_id: saD_i d_t ype j i INPUT - SAP ID of SAP to close 
user_id: *cellT C INPUT - user identifier 
VAR return_code: c I ose.i nt er net_sa p_status ) ; C OUTPUT 

C Return codes from cl ose_i nternet_s ap 

i 

TYPE 

cl ose_in ternet_sap_status * I {. 

c I ose_sap_successf ul * i SAP was closed successfully 

sap_a7r eady.closed* i Attempting to dose already closed SAP 

mismatch.user i d ) } C Input user_l d doesn't match SAP entry 
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%J 
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3.3 £EfiIiiaAIlIUi-E£-tC!SSUilIIl-IIILES 



This is not a direct service that Routing M-E provides to 
applications and M-Es in the DI but occurs automatically. 
Local community title/addresses are learned from Community 
Title configuration commands. Remote ones are contained in 
RIOUs from other systems. Routing M-E registers the local 
title/addresses with the Directory M-E. 

As part of RIOUs* multi-homed systems send community 

title/addresses oairs throughout the catenet. Receiving 

systems register the received t i t I es / addr esses with the 
Di rectory M-F. 



3. A HEMQEK-IIILES-aAIA-SICEE 



The Network Titles Data Store is built by Routing M-E for 
Directory M-E whenever a full update of the LCR-DS is 
Processed. Its format is described in section 8.7. In 
general* this data store is a list of all accessible networks 
sorted by the number of hops from this system from lowest to 
highest. Directly connected networks have a hop_count of CO. 



3.5 ££fi£D£ASI-DE-milS-ia-riIEE£-EQUIItl£Ji=£S 

RIDUs are generated by systems that have more than one 
directly connected network. Every 30 second or when some 
attribute of a directly connected network or local community 
title changes* an RIDU describing the directly connected 
networks and local community titles is broadcast on all active 
directly connected networks. 

Also* when a multi-homed system receives an RIDU from another 
system* the received RIDU is saved and re-broadcast on all 
networks that are currently active and are marked as Routing 
Information Networks* except the one on which it was received. 
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The following performance parameters have been established: 



o 



The processing of received RICUs 

with 10 networks 

3 DCN»s generation of 

20 Relaying System routing taMe 

Ooen i ng a SAP 
Closing a SAP 
Memory requirements for code 



< _ .25 msec 



< 
< 
< 
< 



.5 msec 

.2 msec 

.1 msec 

4K bytes 
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5.0 £iaiI£-SIAIE-!JACJ:I!i£ 



The "Pouting M-E Protocol Spec i f I ca t i on" to describe the 
Finite State Hachine for this ME is in a separate document as 
an attachment to the GDS. 
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fc.O LD£_EEES££ES_£EN££AIEE 



6.1 L££=P.S-£E£iEEAIE& 



Whenever the LCR-DS is rebuilt in a system, the following log 
message is generated: 



LD£-££££A££.I£ 

r.ie.l crds_r etui It 



o 



Q£S££I£IIii£_K£SaA££ 

LCR-DS Rebui It 

• MASH ?! LQ£-fiS£-filiEEEE 

• • 
■ i 

+ + ♦ + 

• MASK 5! LOG MESSAGE BUFFEP.PTR'"' (variable part) J 
+ + ♦ 1- + + + 

! fixed text ',', type lvalue i description ! 

•TYPE * 5!binary !4 Chars {Full or partial update ! 
} ! {octets ! ' 

+ ++ + + * 

CE£tatit-I2ii£ia^_Efl£niai-Eiaa£l£ 

83/08/04 11.00.35 12345678«JABC 

LCP-DS Rebui It 
TYPE - FULL 



O 



NOTE: The date* time and originating system address are taken 
from the PDU header. 



CONTROL DATA PRIVATE 



^>' 



6 



6-2 

POUTING M-E ERS 

07/25/84 

fc.O LC6 MESSAGES GENERATED 
6.2 RIDU WITH UNKNOWN IC 



6. 2 SinU-HIUJ-lWSHri'ifcLID 

Whenever an Routing Information Data Unit (RIDU) is received 
whose ID field is unkonwn* the following log message is 
generated: 

LI3£-ttES£A£E-ID. 

r_me_unknown_r i du_i d 

tt£S£EI£m£-EEiSA£E 

RITU with unknown ID 

flASK ! ! L3£-fl££-£UE£££ 

• i 

• i 



J MASK J! LOG_h*ESSAGE_BUFFER_PTR* (variable part) 

! fixed text {{ tyoe {value J description 

JPIDU = {{binary {1..512 {The PIOU with unknown IC 

! {{octets {octets { 



DfifitJEiiiii:-I2isfilax-EfltBiai-£jf4ffl£l£ 

63/08/04 11.00.35 123456789ABC 

PICU with unknown ID 

R IDU= 12345 67 e<50 abed ef 01234 56 



NOTES The date* time and originating system address are taken 
from the PDU header. 



• + 
•+ 
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6.3 UNKNOWN MESSAGE TO PIDU PPOCESS 



6.3 UUJiii£UliUi£SSA£E-IQ-£-I£U-£ED£ESi 



Whenever process.recvd.R IDUs receives an Intertask message 
whose workcode is not "r_me_ri du_msg% the following log 
message is generated: 



r_me_unknown_msg_to_P. IDU.pr oc 

EEE££I£II}iE-£ESEA£E 

Unknown intertask message to RIDU process 

EASK \ ! LQ£-fii£-£UEE££ 

• MASK S! LOG..MESSAGE_BUEFEP_PTP' v (variable part) 

• fivaH *«v«- •• type lvalue 5 description 



fixed text 



{Message = 



+• 



.++ + + . 

{{binary !1..?12 {The Intertask message 
! {octets ! octets ! 

•++ + + 



Q££ulA£.£is£l&x-Eaifi£i-Ex£a&l£ 

83/08/04 11.00.35 123456789ABC 
Unknown intertask message to RIDU process 
Message*1234567890abcdef012 34 56 



NOTE* The date* time and originating system address are taken 
from the PDU header. 



— + 



— + 

• 
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f.O LOG MESSAGES GENERATED 

6. A UNKNOWN MESSAGE TO LCRDS UPDATE 



6.4 UMt!M5U:ESSA.SE.Ifl_L£ELS_llE2AIE 



Whenever update LCRDS receives an intertask message whose 
workcode Is not "r_me_part_upda te_LCRDS n or 

"r_me_ful l_update_LCRDS M > the following log message is 
generated: 



L12£_n£SSA££-ID. 

r_me_unknown_!rsg_LCPDS_update 

££S£EIEmE-£ESSA£E 

Unknown intertask message to LCRDS update 

flA£K ! ! LQ£-HSfi.£U££££ 



+ ♦+. 



i MASK Si LDG_MESSAGE_BUFFEP_PTR* (variable par-) 

+ _ ++ + + — — — . 

! fixed text !! type {value ! description 

{Message » {{binary {1..512 {The Intertask message 
! {{octets {octets J 



CfiStAiJBt-lliiJBlai-EttLiiLat-ERafflftlfi 



63/08/04 11.00.35 123456789ABC 
Unknown intertask message to LCRDS update 
Message=1234 567890abcdef0123456 



NOTE: The date» time and originating system address are taken 
from the PDU header. 



— + 
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7.0 INITIALIZATION 



7.0 IHIIIAUZAIIQM 



^Lk»J^ 



o 



After It is loaded* Routing M-E performs the following 
seouence of steps to initialize itself. It is to be noted 
that in Release 1.0* only Xerox Internet and Transport are 
used. Also* the LCR-DS and 3B SAP data stores are all empty. 



11 



2) 



3) 



A) 



Open a 3A SAP via direct call interface described in the 
Generic 3A Intranet ERS and wait for unsolicited status 
about directly connected networks. This 3A SAP is also 
used for transmitting and receiving PIDUs. 



is received in a direct 
Generic 3A ERS. In 
and 



mod i f i ed. 



Process 3A status information as it 
call interface described in the 
general* Local DCN-DS entries are created 
The following information is supplied: 

- network ID of particular network 

- network status 

- pointer to network information block 

- system ID of receiving system 

- whether this is a broadcast/multicast network 

Broadcast a request_r i du_ i nf o RIOU (described . in section 
3.3) on the first network described by 3A. The reason for 
this is to ask for all received RIDU information in order 
for Internet to become operational sooner. The only 
systems that would respond to this request are those that 
have the responsibility for generating and distributing 
RIDUs. These would Include all the NI's on this network 
and any HDI's configured to perform this function. This 
prevents a flood of responses from all the systems on the 
network • 



Process PIDUs as they arrive 
probably he the result cf the 
step 3 above. 



in the normal way. 
r equest_r idu_ i nf o 



Most wl I I 
issued in 



5) When the first LORDS is built 
network described by a 3A status 
users to open 3B SAPs. 



as a result of 
update* a 1 1 ow 



the first 
Internet 



It can be seen that once the 3A SAP is opened* Pouting M-E 
operates as it always does! Information is received from 
Generic 3A and RIDUs from other systems and processed. Local 
and received DCN entries are created and updated. 
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remote ^ data 
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Pirus. 
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6.0 TATA TYPES 



P.C UI^lllLl 



The following CYBIL records are used in the Routing tf-E. 



8 . 1 L£ASI_£QSI-EnUIIti£.C£I A-UCEE.iLLErQSl 



least_cost_rout i ng data store entries describe the path 
from this system to a specified network. 

YPE 
least_cost_r out i ng_ds_entr y * record 
aggregate_cost: integer* 

aggregate_cost_r at io: -8000(16) .. 07ffM16J* 
pdu_count: integer* 
relay.count: .. 0ffff(16)* 
next_hop_networ k_i d : network_id_type* 
ne-xt_hop_syste«n_ id! system. id_type* 
oarent_network_i d: net wor k.i d_t ype* 
congested: boolean* 
r el ay_restr i cted : boolean* 
unused: boo lean* 
obsolete: boolean* 

I oca l_dcnds_ptr : *l oca l_dcnds_entry» { If d irec 1 1 y_connected 
next_entry: A teast_cost_routing_ds_entry; 
recend; 



o 
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8.0 DATA TYPES 

8.1 LEAST CCST ROUTING D&TA STORE (LCP-DS) 



c 

C Poute Table Pow: 

i group of LCR-DS entries for a particular Network ID - 

i 

TYPE 

least. cost. routi ng.ds.row = record 

network.id: networ k_i d.type* 

changed: boolean* 

d i rectly. connected: boolean* 

al i as.ex ists : boolean, 

wul t icast: boo I ean, 

broadcast.address: system. i d.type* 

va I id.lcrds.entr y.count : .. Cffff(16)» 

f i rsOcrds .entry: "I e as t.cos t.r cu t i rg.ds.entr y* 

next.row: A 7east_cos t.rout i ng.ds.row* 
recend; 

VAP 

current.! crds.ptr : tXDCL] A I east. cos t.r out i ng.ds.row; 



6.2 ALIAS JLISI 



{ • • 

C Alias List to relate ecuivatent NW/system addresses 

{ form multi-homed systems 

{ 

TYPE 

al i as. I i st.entry = record 
inactive: sy stem. address * 
equivalent: sys t em.addr ess* 
next. entry: *a I i as. I i st.entry, 
recend* 

system.address * record 
network.id: netwo rk.i d.ty pe> 
system.id: systeir.i d.type* 
recend* 

VAP 

alias.list: [XDCL3 *a I i as. I i st.entry ; 
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8.3 RGUTING INFORMATION DATA UNIT (PIDU) 



8 . 3 ££UII^_IN£a£!iAIICN.CAlA -^II-lEIQJJl 
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{ values for id fietc in SIDUs 

i 

CONST 

r idu_nul I = 0* 
normal_ridu - 1* 
reguest_r i du_i nfo ■ 2J 



C 



■T Header for Routing Information Data Unit (PIDU) 
f this header is followed by dcn_def i ni t ion_entr ys 
{ 
TYPE 

rout i ng_ infold at a_uni t_hdr * packed record 

ids •• 0fftl6)» C kind of data unit » norma t_r i du 

rout i ng_inf o_ch anged s boolean* 

t i t I e_i nfo_changed: boolean* 

dcn.count; .. 3f(16)» 

seauence_noi integer* 
r ecend: 



i Peouest for all received RIDU information 
•C Broadcast by system being initialized 
C 
TYPE 

reques t_for_recei v ed_r i du_i nf o = id: C .. Cff(16)J 

{ ID * requester i du_i nfo 



^to**^ 



I 
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e.O D*TA TYPES 

8.3 PCUTING INFORMATION DATA UNIT (RIDU) 



b 



One dcn.def init i on.entry exists for each directly connected 
network in the originating system followed by the specified 
-number of commun i ty_t i t J e entries 



i 

i 

TYPE 

dcn_def ini ti on.entry * packed record 
system_address: system_address_type» 
cost: .. Offff(16>> 
communi ty_ti tl e.count: .. 0ff(16)> 
fillers .. 01 (16)» 
r out i ng_inf o_changed: boolean* 
t i t I e.inf o_changed: boolean* 
ne twor k_act i ve : boolean* 

s ap_3a_congest i on: (none* levell* Ievel2)> 
rel ay„r estr i cteti: boolean* 
case broadcast.network : boolean OF 

= TRUE = 

broadcast_address: system_id_t ype* 
casend* 
r ecend* 



i 



A corresponding number of communi ty«.t i t le_entr ies exist for 
communi ty.ti t le_count. The title.name field only contains 
the number of characters specified by the title_length field 

commun i ty_ti t I e_ entry = packed record 

address: system_i d_t ype* 

filler: .. 3* 

title length: 1 .. 32* C length 

title.name: string < * <« 32)* C title.length specifies size 
recend J 



{ The Local PIDU: seouence no* header ptr and data buffer 

i 
VAP 

I oca l_r i du_sequence_no: integer* 

locallr i du_hdr_ptr : "routi ng.i nf o_da ta_un i t_hdr» 

local.ridu: buf_ptr> 

local.ridu.semaphore: lock.type; i To lock Local RIDU 



o 
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8.0 DATA TYPES 
|^l 8.4 LOCAL DIRECTLY CONNECTED DATA STORE (LDCN-DS) 

8. A mtAl^MEidLX-Cn&NECIED JUIi-mSE-XLCLiLrllSI 



{ En 
£ 
C 

TYPE 
to 



re 



tries for local den data store 

these entries describe directly connected networks 



ca l_dcnds_entr y ■ record 

cdna_r oute.inf o.nw: boolean* 

network.status: networ k_status_type» 

cdna_rout i ng.addr : sys tem_i d_t ype* 

irax_pdu_si ze: .. 65535* 

rfcn_ entry: *dcn_cefirition_entry» 

next_entry: * I oca I _dcnds_ent r y> 

comm.titles: "array C * 3 of comtr_t \ 1 1 e_en try_i d» 

c e n d ; 



•C pointers to data stores concerning local den data stores 
{ and related den info to broadcast to otner systems 
{ 

VAP 

f i rst_»ocal_dcnds_entry: [XCCL3 A I oca 1_dcnds_entr y* 
ldcnds_semaphore: [XDCL3 lock_type; 



8 . 5 EE£EIJ£Efi_mL£ILl-LCBJ»ECI££-GAIA-£I£££-lEfl£N=nSi 



{ entries for received den data store describing current info 

C about networks connected to relay systems 

C 

TYPE 

recei ved_dcnds_entry ■ record 

sequence.no: integer* 

timestamp: Integer* 

next .entry: A recei ved_dends_entr y> 

dcn.entry: array C * 1 of dcn_inf ormat ion.type* 
recend; 



o 



{ pointers to data stores concerning received den data stores and 
C related den info received from other systems 

i 
VAP 

recei ved_dcnds_otr : IXDCL] A r ece i ved_dcnds_entr y» 
r dcnds.semaphore: CXDCL1 lock.type; 

CONTROL DATA PRIVATE 
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8.0 DATA TYPES 
--> 8.5 RECEIVED DIRECTLY CONNECTED DATA STORE (ROCN-DS) 



D 



8.6 -£Q!irU!IlII-IIILE-tAIi-SIQ££ 



i 

C Entries describing community title entries. 

{ For each comm_t i t I e_ds_entr y> there exist one or more 

C comm_address_entrys (one for each tranlation) 

TYPE 

corom_t i t I e_ds_en tr y « record 

first_addr: A comm_adar ess_entr y> 

next_entry: A comir._t i 1 1 e_ds_ertry> 

title: string ( * <= 32), 
recend* 

comm_addr ess_entr y = record 

ids comm_3ddress_i d» 

occurrences: •• 0fftl6)» 

multicast_addr: system. address_type> 

directory.id: dir_id_rec> 

next_entry* A comm_addr ess_entr y» 
r e c e-n d » 

comm_t i t I e.entry.i d * record 

entry_ptr: *comm_t i t I e_ds_entr y» 

ids comm_addr ess_i d» 

member_of _comm : boolean* 
recend* 

comm_addr ess_i d » .. 0ffll6)s 



VAP 

f irst_comm_t i t le_ds_entry: A comm_t i t !e_ds_entr y. 
comm titles semaphore: [XDCL3 lock_type; 



o 
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8.0 DATA TYPES 

8.7 NETWORK TITLE DATA STOFE 



8.7 &EIHQ£li-IIILE-D£IA-SIE&E 



This record is for "broadcast network rr" 
used by Directory M-E. The data store is 
a full update of the LC&-DS occurs, 
for each accessible network and 
{ hop count « for directly connected 



i 
< 

t 
C 
{■ 
TYPE 

network_ti tl e_entr y * record 
address: system_address_ty pe> 
hop.coun t! 0. .15 t 

next_entry: A ne t wor k_t i 1 1 e_entry> 
recend; 



titles that are 
created whenever 
Entries are created 
sorted by hop count 
network) • 



VAP 

network.ti tles.ptr s CXCCLI ' 
rw.t i t I es.semaphore: [XCCL1 



network_titl e.entry* 
lock_t>pe; 



T^Mli"'' 



^kusir 
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P.O DATA TYPES 

8.8 INTERNET SAP TA3LE 

8.8 IMI££MEI_SA£_IAiL£ 

{. 

i The INTERNET SAp table maintains Service Access Points for 

C INTERNET. An INTERNET user must open an INTERNET SAP 

C (which specifies a procedure address where to deliver 

C INTERNET data indications destined for that SAP) in order 

{ to user INTERNET. 

C 

{. For each open SAP there is one S AP.TABLE.ENTRY and one entry 

{ in the array of INTEPNET_SAP_TABLE_TYP£ (which points to the 

C SAP_TA8LE_ENTRY) . The array is in ascending order and 

f contains only entries for open SAPs. 

C 

TYPE 

internet_sap_tabl e.type - record 

sap_id: sap_id_t ype> 

entry.ptr: *sap_tab le_entry» 
recend* 

sap_t ab I e_entr y * record 

user_id: *cell# { User identifier 

destination: des t ina t i on_3b_sap_i f > -C User indication PPOC 

force_close: f orce_c I ose_i f , t User force close SAP PRDC 

recend; 

VAP 

internet_sap_ table: 

CXDCL] "array [ * ] of i nter ne t_sap_tab I e_type J 



^u*'' 
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9.0 GLOSSARY 



a»A 



9.0 &LDSSAEI 



Alias_Llst: List of network/system ID pairs: Indicates an 
eauivalent network/system address when the network 
access to a particular system becomes inactive. 
Internet uses the A1ias_List when the specified 
destination address of a PDU Is Inactive. 

OCN: Directly Connected Network: networks which are directly 
connect to this systeir. 



LCR-DS* Least Cost Routing Data Store: 
maintained by Routing M-E and used 
determining where to send 38-PDUs 
final dest i na t i on. 



The rout i ng table 
by Internet for 
on the way to the 






LDCN-DS: Local Directly Connected Data Store: information 
about networks directly connected to this system. 

RDCN-DS: Received Directly Connected Oata Store: information 
.about networks directly connected to other systems in 
the catenet wrier is learned from PIDUs received from 
multi-homed systems. 

RIDU: Routing Information Data Unit: broadcast from 
multi-homed systems indicating the status of directly 
connected networks and multicast titles in order that 
all systems can build LCP-DS's. 
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ICO 'ABORTS AND RECOVERY 

10.0 A.fi2m_A.N.p._aE£DJ££I 



t) 



10.1 IHI££!i£I 



When Internet is called either by an Internet user or 
Intranet* It takes over the current task and Informs the Exec 
of an Internet recovery procedure. If Internet falls* an 
error recovery routine Is called. All buffers and stacks 
related to the failed task are released hut other Internet 
processes are unaffected. Since the Internet datagram service 
does not guarantee delivery* the sender and receiver are 
unaffected. 



10.2 EQ!iIING._M = £ 



When the task for Routing M-E is started* it is given some 
stack space. The initialization within Routing M-E passes the 
address of the error recovery routine en the stack. If the 
Routing M-E fails abnormally* the system ancestor is informed 
and it gives control to this special error recovery routine* 
which informs 3B entities of its failure and closes all the 
open 3B SAP's. At the same time* no Internet SAPs can be 
opened. 

After the on-line dump procedure is defined* the memory will 
be dumped for debugging. As the route tables are not 
available any more* the DI has to be initialized. 



^lyyuinr 
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